Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Allow controlled search options #186

Open
wants to merge 10 commits into
base: main
Choose a base branch
from
Open

Allow controlled search options #186

wants to merge 10 commits into from

Conversation

joeyparis
Copy link

Prior to version 3 if nothing (as in null/undefined, not an empty array) was returned for the getOptions prop the component would continue to use the values passed in the options prop. This is helpful when you want the options to be controlled by your own component rather than managed by the SelectSearch component. This update should not affect existing behavior.

Here's a rough example:

const Dropdown = ({ default_options }) => {
	const [options, setOptions] = useState(default_options)

	const advancedOptionFunction = (search) => {
		// ...do advanced search things
		const new_option = () => [] // pretend this gets new options
		setOptions(new_options)
	}

	return (
		<SelectSearch
			search
			options={options}
			getOptions={(q) => {
				advancedOptionFunction(q)
				// Note the lack of return. Returning an array or Promise
				// would still act the same as before this pull request
			}}
		/>
	)
}

@vercel
Copy link

vercel bot commented Apr 28, 2021 •
edited
Loading

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/tbleckert/react-select-search/DoDdb4yfgT85Qof485R4Hgyvu2jT
✅ Preview: https://react-select-search-git-fork-joeyparis-control-853c00-tbleckert.vercel.app

@JoeyLeadJig
Add full test coverage for equal.js
e688fce 
Consider making fast-deep-equal an optional dependency and using a less robust one natively
@joeyparis
Copy link
Author

joeyparis commented May 21, 2021 •
edited
Loading

I was able to improve test coverage overall, but I took the equal.js code and relevant tests from fast-deep-equal. We might be better off removing equal.js and making fast-deep-equal an optional dependency and falling back to a more simple deep equal (like JSON.stringify or even just a one-level object comparison) if fast-deep-equal isn't included.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@joeyparis @JoeyLeadJig